Vehicle, communication system and communication method using the same

ABSTRACT

The present disclosure provides a communication method comprising registering a public key for a vehicle, generating a pseudonym ID, transmitting the pseudonym ID, verifying whether the vehicle is registered, and storing a first transaction. Registration of the public key for the vehicle comprises receiving a service with a service provider. The pseudonym ID is generated based on the public key. The pseudonym ID and vehicle data are transmitted to a road side unit. Verification as to whether the vehicle is registered with the service provider is performed based on the transmitted pseudonym ID. A transaction including the pseudonym ID and the vehicle data is then stored in a database of the service provider according to a result of the verification.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority from Korean Patent Application No. 10-2020-0000759 filed on Jan. 3, 2020 in the Korean Intellectual Property Office, and all the benefits accruing therefrom under 35 U.S.C. 119, the contents of which are incorporated by reference in their entirety.

BACKGROUND 1. Technical Field

The present disclosure relates to a vehicle, a communication system and a communication method using the same.

2. Description of the Related Art

Mobile communication technology enables information to be shared between a wireless device and a land-based communication station. Fifth generation (5G) networking is a technology standard for mobile communication networks. Information from smartphones, aircraft, and automobiles may be accessed through 5G networks.

Automobiles are an example of a system that can utilize 5G communications. Automobile information may contain data such as traffic volume, road conditions, or vehicle motion data. This data may be collected and analyzed in by a service provider in real time to optimize traffic flow, provide emergency support, or provide vehicle location information (e.g., for navigation or law enforcement purposes).

When service provider collects vehicle information, the anonymity of a user may be compromised. Thus, in many cases user privacy cannot be guaranteed or protected. An anonymous ID could be used to increase privacy, but this may prevent the identity of the user's vehicle from being verified. As a result, the user may not be able to collect or monitor information about their vehicle.

Therefore, there is a need in the art for acquiring vehicle data capable of verifying the identity of the vehicle while ensuring the user's privacy. This could enable users to monitor the information about their vehicle without compromising privacy.

SUMMARY

Aspects of the present disclosure provide a communication method capable of verifying an identity of a vehicle while ensuring privacy of the vehicle.

Aspects of the present disclosure also provide a communication method capable of publicly managing vehicle data to prevent a service provider from denying a fact that a vehicle has provided the vehicle data to the service provider. However, aspects of the present disclosure are not restricted to those set forth herein. The above and other aspects of the present disclosure will become more apparent to one of ordinary skill in the art to which the present disclosure pertains by referencing the detailed description of the present disclosure given below.

According to an aspect of the present disclosure, there is provided a communication method comprising registering a public key for a vehicle which receives a service from a service provider; generating a pseudonym ID corresponding to the public key; transmitting the pseudonym ID and vehicle data; verifying whether the vehicle is registered with the service provider based on the transmitted pseudonym ID; and storing a first transaction including the pseudonym ID and the vehicle data in a database of the service provider according to a result of the verification.

According to another aspect of the present disclosure, there is provided a communication system comprising a wireless communication module configured to receive a pseudonym ID and vehicle data from a vehicle; a network communication module configured to transmit the pseudonym ID and the vehicle data to a service provider providing a service, and to receive an initial secret value for the service; a base station arithmetic unit configured to verify whether the vehicle is registered for the service through the received initial secret value; and a first base station server configured to form a blockchain transaction including the pseudonym ID and the vehicle data according to a verification result of the base station arithmetic unit, and to store the blockchain transaction.

According to another aspect of the present disclosure, there is provided a vehicle comprising a sensor configured to acquire vehicle data; a security module configured to store a private key, the security module comprising a random number generator configured to generate a plurality of first random numbers that vary over time; a wireless communication module configured to receive a public key generated by an operation of the private key and to receive an initial secret value provided by a service provider; and a vehicle arithmetic unit configured to generate a pseudonym ID based on the public key, wherein the wireless communication module is further configured to transmit the pseudonym ID to verify that the pseudonym ID is generated based on the initial secret value.

According to another aspect of the present disclosure, there is provided a method of communication comprising receiving an initial secret value from a service provider; receiving a pseudonym ID and vehicle data from a vehicle; verifying that the vehicle is registered with the service provider based on the pseudonym ID and the initial secret value; and storing a transaction comprising the pseudonym ID and vehicle data based on the verification.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects and features of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings, in which:

FIG. 1 is a diagram illustrating a structure of a communication system according to some embodiments;

FIG. 2 is a block diagram illustrating the communication system according to some embodiments;

FIG. 3 is a flowchart illustrating a communication method of the communication system according to some embodiments;

FIGS. 4 and 5 are diagrams explaining step S100 of FIG. 3;

FIG. 6 illustrates elliptic curve cryptography used in the communication method according to some embodiments;

FIG. 7 is a diagram explaining steps S200 and S300 of FIG. 3;

FIG. 8 is a diagram explaining steps S400 and S500 of FIG. 3;

FIGS. 9 to 11 are diagrams explaining a data storage method used in the communication method according to some embodiments; and

FIG. 12 is a diagram explaining steps S600 and S700 of FIG. 3.

DETAILED DESCRIPTION OF THE EMBODIMENTS

The present disclosure relates to mobile communications between an automobile and a communication network. Embodiments of the present disclosure relate to a method for verifying the identity of a vehicle without comprising the privacy of a user.

As new mobile communications technology becomes commercially available, there is an increasing need for obtaining a large amount of data from communication devices. For example, service providers who provide a services to vehicle users have attempted to acquire vehicle data such as a traffic volume, road conditions, the occurrence of natural disasters, and the like from vehicles that receive the service. In some cases, these service provides immediately analyze the vehicle data for use in providing the service.

When a service provider acquires the vehicle data a user's may not be protected. For example, ins some cases a travel route of the vehicle can be tracked through the data transmitted from the vehicle. However, when an anonymous ID is used to protect the privacy, the identity of the vehicle which generated data may not be verifiable. This may make it difficult to provide the user with a reward or incentive for providing the data. In other words, there can be a trade-off between the privacy and the identification of the vehicle. Embodiments of the present disclosure provide a method for enabling vehicle identification that does not compromise the privacy of a user.

According to one embodiment, a method of communication includes registering a public key for a vehicle, generating a pseudonym ID, transmitting the pseudonym ID, verifying whether the vehicle is registered, and storing a first transaction. Registration of a public key for a vehicle may include comprises receiving a service from a service provider. Generation of the pseudonym ID may be based on the registered public key. The pseudonym ID and vehicle data may then be transmitted, and verification of whether the vehicle is registered with the service provider through the transmitted pseudonym ID may be performed. In some cases, a transaction, including the pseudonym ID and the vehicle data, is stored in a database of the service provider according to a result of the verification.

Embodiments of the present disclosure provide data from a vehicle to a road side unit. The road side unit may contain a server and may use blockchain technology to perform calculations on the data. The calculations may be provided to a core network, which can be accessed by a service provider. Data may then be provided back to the vehicle, where a user may decipher the data.

Hereinafter, exemplary embodiments of the present inventive concept will be described with reference to the accompanying drawings.

FIG. 1 is a diagram illustrating a structure of a communication system according to some embodiments. FIG. 2 is a block diagram illustrating the communication system according to some embodiments.

The communication system, according to some embodiments, may be a fifth generation (5G) communication system, or a pre-5G communication system such as a fourth generation (4G) communication system.

For example, the 5G communication system may be implemented in an ultra-high frequency (millimeter wave) band (e.g., 60 GHz band). Techniques such as beam-forming, multiple input multiple output (MIMO), full dimensional MIMO (FD-MIMO), array antenna techniques, analog beam-forming, and large scale antenna techniques may be applied in the communication system to reduce propagation loss of radio waves and increase the transmission distance thereof.

The communication system, according to some embodiments, may include a plurality of vehicles 100. The vehicles 100 may include first to fourth vehicles 100_1 to 1004, a plurality of roadside units 200 including first and second roadside units 200_1 and 2002, a core network 300, a service provider 400, and the Internet 500.

The first roadside unit 200_1 may communicate with the first and second vehicles 100_1 and 100_2 to transmit and receive data. The second roadside unit 200_2 may communicate with the third and fourth vehicles 1003 and 1004 to transmit and receive data.

The first and second roadside units 200_1 and 200_2 include first and second roadside unit servers 240_1 and 2402, respectively. Each of the first and second roadside unit servers 240_1 and 240_2 may be components of a blockchain network. The formation of the blockchain network will be described later.

The first and second roadside units 200_1 and 200_2 may communicate with the core network 300. Communication with the core network 300 may be used to communicate with a service provider 400. For example, the first through fourth vehicles 100_1 to 100_4, the roadside units 200_1 and 200_2, and the service provider 400 may be connected to, and communicate through, the Internet 500.

The vehicle 100, according to some embodiments, may have a mobile communications capability. The vehicle 100 may also represent or be referred to by a term such as a terminal, a user equipment (UE), a mobile station (MS), a user terminal (UT), a mobile subscriber station (MSS), a subscriber station (SS), an advanced mobile station (AMS), a wireless terminal (WT), a machine-type communication (MTC) device, a machine-to-machine (M2M) device and a device-to-device (D2D) device or the like.

The vehicle 100, according to some embodiments, may include a security module 110, a wireless communication module 120, a sensor 130, and an arithmetic unit 140. In the present disclosure, the vehicle 100 is used as an example of a transport device, but the present disclosure is not limited thereto. The vehicle 100 may be another communication device or another transport device such as a train, a ship or the like.

The security module 110 may perform operations to execute a cryptographic protocol, securely store sensitive information such as a cryptographic secret key, and provide hardware (H/W) security. The security module 110 may include a random number generator 111 for generating a random number, where the random number varies over time. The security module 110 may be a hardware security module (HSM), a subscriber identification module (SIM), an embedded secure element (eSE), or the like.

The security module 110 may support a security-related library with, for example, an elliptic curve cryptography (ECC) public key or a Rivest-Shamir-Adleman (RSA) public key. In the present disclosure, the ECC will be described below as an example, but the present disclosure is not limited thereto.

In some embodiments, the security module 110 may store a private key (x_(i)), a public key (Q_(i)), and an initial secret value (s), which will be described later. Once stored, the private key (x_(i)), the public key (Q_(i)), and the initial secret value (s) are not exposed outside the security module 110. The private key (x_(i)), the public key (Q_(i)), and the initial secret value (s) may be issued by a trusted third party. The security module 110 may further store another public key (Q_(i, s)).

The wireless communication module 120 may perform functions for transmitting and receiving signals through a radio frequency channel. For example, the wireless communication module 120 may perform a conversion function between a baseband signal and a bit string according to a physical layer standard of the system. When transmitting data, the wireless communication module 120 encodes and modulates the bit string to be transmitted to generate complex symbols. When receiving data, the wireless communication module 120 demodulates and decodes the received baseband signal to restore the bit string.

The wireless communication module 120 up-converts the baseband signal into a radio frequency (RF) band signal to transmit the signal through an antenna. Additionally or alternatively, the wireless communication module 120 down-converts the RF band signal received through the antenna into the baseband signal. In some examples, the wireless communication module 120 may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a digital to analog convertor (DAC), an analog to digital convertor (ADC), and the like.

The wireless communication module 120 may further include a plurality of transmission/reception paths. The wireless communication module 120 may further include at least one antenna array configured with a plurality of antenna elements. The wireless communication module 120 may be configured with a digital circuit and an analog circuit (e.g., a radio frequency integrated circuit (RFIC)). In some cases, the digital circuit and the analog circuit may be implemented in one package. The wireless communication module 120 may further include a plurality of RF chains. Additionally or alternatively, the wireless communication module 120 may perform beam-forming.

Further, the wireless communication module 120 may include different communication modules to process signals of different frequency bands. Furthermore, the wireless communication module 120 may include a plurality of communication modules to support different wireless access techniques. For example, the different wireless access techniques may include Bluetooth low energy (BLE), wireless fidelity (Wi-Fi), WiFi Gigabyte (WiGig), a cellular network (e.g., long term evolution (LTE)), and the like. Further, the different frequency bands may include a super-high frequency (SHF) (e.g., 2.5 GHz, 5 GHz, or the like) band and a millimeter-wave (e.g., 60 GHz) band.

The wireless communication module 120 transmits and receives signals, as described above. Accordingly, in the following description, the transmission and reception performed through the radio frequency channel are considered to include the above-described processing performed by the wireless communication module 120.

The sensor 130 may be, e.g., a smartphone, a sensor for detecting internal information of the vehicle, a black box for imaging conditions of a road where the vehicle travels in real-time, or the like. In some examples, the sensor 130 may image the front and rear regions of the road where the vehicle travels in real-time to detect objects such as vehicles, road conditions, and the like from the captured image data by applying an object detection algorithm. Thereafter, the sensor 130 may provide at least one among type information, location information, and movement information of the detected object.

The arithmetic unit 140 may include various kinds of hardware (or processor) accelerators or software. For example, the arithmetic unit 140 may include a hardware accelerator such as a central processing unit (CPU), a graphics processing unit (GPU), or the like. Operations such as add, multiplication, shift, XOR, AND, OR, NOR, and NAND may be performed in the hardware, as well as operations for processing RSA and ECC public keys, such as modular operations of modular addition, modular multiplication and the like.

The roadside unit 200, according to some embodiments, may be a terminal node of a network that directly communicates with the vehicle 100. In the present disclosure, operations described as performed by the roadside unit may be performed by an upper node of the roadside unit in some cases. Additionally or alternatively, in a network configured with a plurality of network nodes including a roadside unit, various operations performed for communications with a terminal may be performed by the roadside unit or other network nodes. According to various embodiments, the roadside unit (RSU) may be a fixed station, a base station (BS), a Node B, an evolved-NodeB (eNB), a base transceiver system (BTS), an access point (AP), a macro eNB (MeNB), a secondary eNB (SeNB), or the like.

The RSU 200, according to some embodiments, may include a wireless module 210, a network communication module 220, an RSU arithmetic unit 230, and an RSU server 240.

The wireless module 210 may have the same or similar functions and configurations as the wireless communication module 120 of the vehicle 100. The description for the wireless module 210 of the RSU 200 may also apply to the wireless communication module 120 of the vehicle 100.

The network communication module 220 transmits data to the core network 300, through wired or wireless communications, to transmit data to the service provider 400. According to some embodiments, the network communication module 220 is a unit in charge of connecting to the core network 300 in the RSU 200.

The RSU arithmetic unit 230 may include various kinds of hardware (or processor) accelerators or software. For example, the RSU arithmetic unit 230 may include a hardware accelerator such as a central processing unit (CPU), a graphics processing unit (GPU), or the like. Operations such as add, multiplication, shift, XOR, AND, OR, NOR, and NAND may be performed in the hardware. Additionally or alternatively, operations for RSA and ECC public keys, such as modular operations of modular addition, modular multiplication, and the like, may be performed in the hardware.

The RSU server 240 may process data using mobile edge computing techniques. The mobile edge computing may be applied in a fourth generation (4G) or fifth generation (5G) environments, but the present disclosure is not limited thereto. In the mobile edge computing, a service may be provided to the vehicle 100 by performing computing at the RSU 200 as one edge. The RSU server 240, according to some embodiments, may store the initial secret value (s), a pseudonym ID (PID_(i)), and vehicle data (m), which will be described later.

The RSU server 240 may perform functions of a blockchain node. The blockchain node refers to a computing node capable of forming a blockchain network and maintaining and managing blockchain data based on a blockchain algorithm/protocol. The computing node may be implemented with a physical computing device or a logical computing device, such as a virtual machine. In some cases, a plurality of blockchain nodes may be included in one physical computing device.

The core network 300, according to some embodiments, may provide large-capacity, long-distance voice and data services. The core network 300 is connected to the RSUs 200 and may process user data received through an access network (e.g., to transmit the data to a user of another access network or another communication network). The core network 300 may be connected to the Internet 500, or the like, to transmit/receive data to/from the service provider 400, and provide additional services to users. The core network 300 may include a public switched telephone network (PSTN), an integrated service digital network (ISDN), a wide area network (WAN), a local area network (LAN), and the like, but the present disclosure is not limited thereto.

The service provider 400, according to some embodiments, may include an arithmetic unit 410 and a database 420.

The arithmetic unit 410 of the service provider 400, according to some embodiments, may include various kinds of hardware (or processor) accelerators or software. For example, the arithmetic unit 410 may include a hardware accelerator such as a central processing unit (CPU), a graphics processing unit (GPU) or the like. Operations such as add, multiplication, shift, XOR, AND, OR, NOR, and NAND may be performed in the hardware, as well as operations for RSA and ECC public keys, such as modular operations of modular addition, modular multiplication and the like.

As will be described later, the database 420 may store the pseudonym ID (PID_(i)) and the vehicle data (m) transmitted from the vehicles 100. Additionally or alternatively, the database 420 may share the pseudonym ID (PID_(i)) and the vehicle data (m) stored in the RSU server 240.

According to some embodiments, a method of communication includes receiving an initial secret value from a service provider; receiving a pseudonym ID and vehicle data from a vehicle; verifying that the vehicle is registered with the service provider based on the pseudonym ID and the initial secret value; and storing a transaction comprising the pseudonym ID and vehicle data based on the verification.

In some examples, the transaction is stored in a block of a blockchain. In some examples, the pseudonym ID is generated based on a random number generated and a public key, and wherein the public key is generated based on the initial secret value.

FIG. 3 is a flowchart illustrating a communication method of the communication system according to some embodiments.

The vehicle 100 registers a user specific public key (Q_(i,s)), which corresponds to the vehicle 100, with the service provider 400 (step S100). In the registration step S100, a process between the service provider 400 and the RSU 200 and a process between the vehicle 100 and the service provider 400 may be performed through a secure channel such as a secure sockets layer (SSL) or a transport layer security (TLS), or performed offline. The registration step may include steps described below.

FIGS. 4 and 5 are diagrams explaining the step S100 of FIG. 3. Referring to FIGS. 4 and 5 together, the service provider 400 may provide the initial secret value (s) to the RSU 200 (step S110). The initial secret value (s) is an integer of a set of integers Zn* (Zn*={1, 2, . . . , n−1}, n is described later). The initial secret value (s) may be used to determine whether the vehicle 100 has or has not been registered with the service provider 400 for a service.

The vehicle 100 may share the public key (Q_(i)) and a user ID (ID_(i)) with the service provider 400 (step S120). The security module 110 generates the private key (x_(i)) of the vehicle 100 through the random number generator 111. The private key (x_(i)) is an integer of the set of integers Zn* (Zn*={1, 2, . . . , n−1}). Each private key (x_(i)) may correspond to a vehicle 100. The service provider may provide the public key (Q_(i)) with the vehicle 100 (S130).

The security module 110 generates the public key (Q_(i)) through the arithmetic unit 140 using Eq. 1 below and the private key (x_(i)) may not be opened to other components during the operation of generating the public key (Q_(i)).

Q _(i) =x _(i) G  Eq. 1

In the following, x_(i)G means a value obtained by adding G x_(i) times and G is an arbitrary point on an elliptic curve according to some embodiments. Further, nG=∞ (point at infinity) is satisfied, and n is less than p (p is described later).

FIG. 6 illustrates elliptic curve cryptography used in the communication method according to some embodiments.

Referring to FIG. 6, y²=³+Ax+B is an example of an elliptic curve equation used in the elliptic curve cryptography. A and B are predetermined coefficients used in the elliptic curve equation.

An elliptic curve cryptography (E) corresponding to the elliptic curve equation of FIG. 6 is defined in the Galois field (GFp). GFp={(x, y)|0≤x≤p−1, 0≤y≤p−1}, where x and y are integers, is established.

Accordingly, an elliptic curve digital signature algorithm (ECDSA) related to a signature operation and the elliptic curve cryptography of the communication system, according to some embodiments, may be operated based on y²=x3+Ax+B (mod p).

Given two points of P and Q (P=(x1, y1) and Q=(x2, y2)), the sum of P and Q (P+Q) is defined as follows. When a straight line L connecting the two points P and Q on the elliptic curve meets the elliptic curve at another point R (R=(x3, y3)), P+Q=−R=(x3, −y3) is established (R and P+Q are points symmetric about the x-axis). For example, the sum of the two points on the elliptic curve is defined geometrically.

In other words, the sum of the two points is the x-axis symmetry point of the point at which the straight line connecting the two points and the curve meet. −P represents the x-axis symmetry point of P. In case of P=(x1, y1), −P=(x1, −y1) is established. Further, P+(−P)=∞ (point at infinity) is established.

For the point at infinity ∞, the point is defined that a straight line passing through the point at infinity c is parallel to the y-axis. For example, when the line L is parallel to the y-axis and does not meet another point, the point R is defined as the point at infinity ∞, the point at infinity ∞ is the identity element, and the point symmetric about the x-axis is the inverse element.

The service provider 400 provides the public key (Q_(i)) to vehicle 100 (step S130). The arithmetic unit 410 of the service provider 400 may calculate, as represented in Eq. 2 below, the initial secret value (s) with the public key (Q_(i)) received at the sharing step S120. The arithmetic unit 410 may select a first random value (r_(i)) in the set of integers Zn* (Zn*={1, 2, . . . , n−1}) and calculate the first random value (r_(i)) with the initial secret value (s) as represented in Eq. 3 below to generate y_(i). The arithmetic unit 410 may store the user ID (ID_(i)), the first random value (r_(i)), and the public key (Q_(i)) in the database 420 and provide y_(i) and the public key (Q_(i)) to the security module 110 of the vehicle 100.

Q _(i,s) =sQi  Eq. 2

$\begin{matrix} {Q_{i,s} = {sQ}_{i}} & {{Eq}.\mspace{11mu} 2} \\ {{y_{i} = {r_{i}s^{- 1}\mspace{14mu} {mod}\mspace{14mu} n}},{r_{i}\overset{\mspace{11mu} R\mspace{11mu}}{\leftarrow}Z_{n}^{*}}} & {{Eq}.\mspace{11mu} 3} \end{matrix}$

Eqs. 2 and 3 are merely illustrative, and the present disclosure is not limited thereto.

FIG. 7 is a diagram explaining steps S200 and S300 of FIG. 3.

Referring to FIG. 7, the vehicle 100_1 generates the pseudonym ID (PID_(i)) and a signature (sign_(i) (m)) corresponding to the public key (Q_(i)) (step S200). Referring further to FIG. 7, the vehicle data (m) may be vehicle data (m) 10 acquired through the sensor 130 and may correspond to a message for the service provider 400.

To obtain an arbitrary point (a, b) satisfying point (a, b)=kG on the elliptic curve, the security module 110 may select k in the set of integers Zn*={1, 2, . . . , n−1} as represented in Eq. 4, and may designate “a” as a variable v as represented in Eq. 6 below.

At time t, the security module 110 may calculate as represented in Eq. 5 below by using a second random value (r_(j)), y_(i) and the public key (Q_(i, s)) through the arithmetic unit 140 to generate the pseudonym ID (PID_(i)).

At time t, an operation may be performed by using a hash function h(m∥t) for the vehicle data (m), the second random value (r_(j)), y_(i), the private key (x_(i)) and the variables v and k to generate the signature (sign_(i) (m)) as represented in Eq. 7 below (in the following, II represents that data is linked and an operation between data is unnecessary). The hash function may include a cryptographic hash function (SHA256), and the present disclosure is not limited thereto when outputting a certain size of data.

$\begin{matrix} {r_{j},{k\overset{\mspace{11mu} R\mspace{14mu}}{\leftarrow}Z_{n}^{*}}} & {{Eq}.\mspace{11mu} 4} \\ {{{PID}_{i} = {r_{j} \cdot y_{i} \cdot {Qi}}},{s = {{{r_{j} \cdot r_{i} \cdot s^{- 1}}{sQi}} = {{r_{j} \cdot r_{i}}{Qi}}}}} & {{Eq}.\mspace{11mu} 5} \\ {{\left( {a,b} \right) = {kG}},{v = a}} & {{Eq}.\mspace{11mu} 6} \\ {{{sign}_{i}(m)} = {{\left( {{h\left( {m{}t} \right)} + {r_{j} \cdot r_{i} \cdot x_{i} \cdot v}} \right) \cdot k^{- 1}}{mod}\mspace{14mu} n}} & {{Eq}.\mspace{11mu} 7} \end{matrix}$

Eqs. 4 to 7 are merely illustrative, and the present disclosure is not limited thereto.

Referring to FIG. 7, the vehicle 100_1, which is one of the vehicles 100, transmits the pseudonym ID (PID_(i)), the signature (sign_(i) (m)), and vehicle data (m) to the RSU 200 (step S300). For example, the wireless communication module 120 may transmit a data set 11 to the wireless module 210 of the RSU in a form of PID_(i)∥m∥ sign_(i) (m)∥v∥t.

FIG. 8 is a diagram explaining steps S400 and S500 of FIG. 3. Referring to FIG. 8, the RSU 200 determines whether the vehicle 100 has been registered with the service provider 400 or not based on the pseudonym ID (PIDi) (step S400).

The RSU arithmetic unit 230 of the RSU 200 may generate a modular inverse w of the signature (sign_(i) (m)), a variable u1, and a variable u2 as represented in Eqs. 8 to 10, respectively, by using the pseudonym ID (PID_(i)), the vehicle data (m), the signature (sign_(i) (m)), the variable v, and the time t received at the RSU at the transmission step S300. As a result, a point (x′, y′) may be generated by using the variable u1, the variable u2, the pseudonym ID (PID_(i)), the point G predetermined on the elliptic curve and the initial secret value (s) stored in the RSU server 240, as represented in Eq. 11 below.

The point (x′, y′) may be equal to kG as represented in Eq. 11 below, and the variable v and x′ generated as the x-coordinate may coincide in a case where the data set 11 of PID_(i)∥m∥sign_(i) (m)∥v∥t received at the transmission step S300 has been generated based on the initial secret value (s) provided by the service provider 400.

As represented in Eq. 12 below, verifying whether x′ calculated by the RSU arithmetic unit 230 is possible and the received variable v coincide or not. Therefore, verifying whether the vehicle 100 has been registered for the service provided by the service provider 400 or not through the step is possible.

$\begin{matrix} {w = {{{sign}_{i}(m)}^{- 1}{mod}\mspace{14mu} n}} & {{Eq}.\mspace{11mu} 8} \\ {u_{1} = {{w \cdot {h\left( {m{}t} \right)}}\mspace{11mu} {mod}\mspace{11mu} n}} & {{Eq}.\mspace{11mu} 9} \\ \begin{matrix} {\left( {x^{\prime},y^{\prime}} \right) = {{u_{1}G} + {u_{2}{PID}_{i}}}} \\ {= {{w \cdot \left( {{h\left( {m{}t} \right)} + {r_{j} \cdot r_{i} \cdot x_{i} \cdot v \cdot s}} \right)}G}} \\ {= {{{{sign}_{i}(m)} \cdot \left( {{h\left( {m{}t} \right)} + {r_{j} \cdot r_{i} \cdot x_{i} \cdot v \cdot s}} \right)}G}} \\ {= {k \cdot \left( {{h\left( {m{}t} \right)} + {r_{j} \cdot r_{i} \cdot x_{i} \cdot v \cdot s}} \right)^{- 1} \cdot}} \\ {{\left( {{h\left( {m{}t} \right)} + {r_{j} \cdot r_{i} \cdot x_{i} \cdot v \cdot s}} \right)G}} \end{matrix} & {{Eq}.\mspace{11mu} 10} \\ {= {kG}} & {{Eq}.\mspace{11mu} 11} \\ {{v?} = x^{\prime}} & {{Eq}.\mspace{11mu} 12} \end{matrix}$

Eqs. 8 to 12 are merely illustrative, and the present disclosure is not limited thereto.

Further referring to FIG. 8, if YES is determined in the verification step S400, the RSU 200 transmits the pseudonym ID (PID_(i)) and the vehicle data (m) to the database 420 of the service provider 400 and the RSU server 240 (step S500). If NO is determined in the verification step S400, the communication method, according to some embodiments, may be ended.

The data set 11 having passed the verification step S400 may be configured as a record rcd of PID∥m∥sign (m)∥t to be stored and transmitted to the service provider 400. Further, the RSU generates a signature with its own public key in record sets 12, 22 and 32 (record set=rcd_1∥rcd_2∥ . . . ∥rcd_n) of the records rcd received for a certain period of time, so that a blockchain transaction trans in a form of RSU∥ECDSA_(Sign) (Pri, record)∥record∥t may be generated to be transmitted to one of the RSUs 200 which generates a blockchain. A public key based authentication technique such as the ECDSA, the RSA, or the like, may be adopted for the signature of the RSU.

Referring to FIGS. 9 to 11, after the transmission step S500, the plurality of RSU servers 240_1 to 240_6 as blockchain nodes may form a blockchain network. The RSU servers 240_1 to 240_6 forming a blockchain-based system manage blocks in a chain-shaped data structure as shown in FIG. 10. Additionally or alternatively, the data in the blockchain may be kept equally at each blockchain node without the control of a central system.

Here, a hash value of the previous block is recorded in each block to refer to the previous block by using the hash value. The header of each block may include a merkle root as shown in FIG. 10, and the block body may store data forming a merkle tree. In such a data structure, as the blocks are stacked, a forgery/alteration on the data recorded in the blocks become more difficult. Therefore, the integrity and reliability of the data can be guaranteed even in a distributed environment.

The data stored in the blockchain is data maintained by the RSU servers 240_1 to 240_6 forming the blockchain network, and one or more blocks recording the data are formed in the chain-shaped data structure. When the data is recorded in each block in a form of a transaction (e.g., transactions #1 to #n), the blockchain data may be used as a distributed ledger. However, the form of data recorded in each block may vary. The formation of the blockchain network is an example of a method for storing data having passed the verification of the present disclosure, and the present disclosure is not limited thereto.

FIG. 12 is a diagram explaining steps S600 and S700 of FIG. 3. Referring to FIG. 12, the vehicle 100 requests a reward for the message provided to the service provider 400 through the RSU 200 (step S600).

The vehicle 100 may transmit the user ID (ID_(i)) with transmitted n data sets (m₁, r₁, t₁) . . . (m_(n), r_(n), t_(n)) (n is an arbitrary number independent of the point G on the elliptic curve) to the service provider 400 through the wireless communication module 120. According to some embodiments, the vehicle 100 may transmit the user ID (ID_(i)) without the data sets.

The service provider 400 rewards the vehicle 100 based on the data stored in the database 420 (step S700). The service provider 400 retrieves a user ID (ID_(i)), which is the same as the received user ID (ID_(i)) and is stored at the registration step S100, to find ID_(i)∥r_(i)∥Q_(i) stored in the database at the time of user registration. As a result, the public key (Q_(i)) and the first random value (r_(i)) may be checked.

In the reward step of the communication method, according to some embodiments, the service provider 400 performs Algorithm 1 (below) to search for a record rcd with a time (t_(k)) which is the same as a time (t_(j)) (t_(k)=t). The reward (R) is provided when the received vehicle data (m) matches vehicle data (m_(k)) in the record rcd of PID_(k)∥m_(k)∥sign (m_(k))∥t_(k) stored in the database 420, and the public key (Q) generated by using the received second random value (r_(j)), and the first random value (r_(j)) and the pseudonym ID (PID_(k)) stored in the database 420 matches the public key (Q) stored in the database 420. However, the present disclosure is not limited to the reward step described above.

< Algorithm 1 > Search ID_(i)∥r_(i)∥Q_(i) (ID_(i)=ID′_(i)) Computes on m_(j)∥r_(j)∥t_(j)(1≤ j ≤n) 1 Reward R=0 2 From j = 1 to j = n 3 Search rcd corresponding to t_(k)=t_(j) 4 If find rcd = PID_(k)∥m_(k)∥sign(m_(k))∥t_(k) 5 satisfying m_(k)=m_(j) 6 then if Q_(i)=r_(j) ⁻¹·r_(i) ⁻¹·PID_(k) 7 then R++ 8 j++ 9 Return R Compensates for R

In the communication method according to some embodiments, the user ID (ID) may be transmitted without the vehicle data (m) of the vehicle 100 and the user may be rewarded based on the vehicle data (m) stored in the database 420 which corresponds to the user ID (ID).

In the communication method according to some embodiments, the vehicle 100 is registered by using the public key obtained through the ECC operation without exposing the private key (x) of the security module 110 to the outside. As a result, embodiments of the present disclosure verify whether the vehicle 100 has been registered for the service or not based on the pseudonym ID (PID_(i)) generated by using the first and second random values, so that the user's vehicle 100 can be identified while ensuring the anonymity thereof.

In the communication method according to some embodiments, when the RSU server 240 forms the blockchain network for storing the vehicle data (m), the RSU server 240 maintains the vehicle data (m) received from the vehicle 100 in the blockchain so that the service provider 400 cannot refuse a reward by denying the vehicle data (m). Therefore, the user can be rewarded according to the vehicle data (m) provided to the service provider 400.

However, the effects of the embodiments are not restricted to the one set forth herein. The above and other effects of the embodiments will become more apparent to one of daily skill in the art to which the present disclosure pertains by referencing the claims. 

1. A communication method comprising: registering a public key for a vehicle which receives a service from a service provider; generating a pseudonym ID corresponding to the public key; transmitting the pseudonym ID and vehicle data; verifying whether the vehicle is registered with the service provider based on the transmitted pseudonym ID; and storing a first transaction including the pseudonym ID and the vehicle data in a database of the service provider according to a result of the verification.
 2. The communication method of claim 1, wherein the registering the public key comprises: storing an initial secret value in a first base station from the service provider, the first base station performing communication between the vehicle and the service provider; and generating the public key based on the stored initial secret value.
 3. The communication method of claim 2, wherein a first base station server of the first base station shares the first transaction and the database with a second base station server of a second base station different from the first base station.
 4. The communication method of claim 3, wherein the first and second base station servers comprise nodes of a blockchain network.
 5. The communication method of claim 1, wherein the public key is generated based on a private key of the vehicle and elliptic curve cryptography.
 6. The communication method of claim 5, wherein the verifying comprises verifying based on an elliptic curve digital signature algorithm.
 7. The communication method of claim 6, wherein the private key is not disclosed to an entity other than the vehicle.
 8. The communication method of claim 1, wherein a first pseudonym ID generated at a first time point among a plurality of pseudonym IDs is different from a second pseudonym ID generated at a second time point different from the first time point among the pseudonym IDs.
 9. A communication system comprising: a wireless communication module configured to receive a pseudonym ID and vehicle data from a vehicle; a network communication module configured to transmit the pseudonym ID and the vehicle data to a service provider providing a service, and to receive an initial secret value for the service; a base station arithmetic unit configured to verify whether the vehicle is registered for the service through the received initial secret value; and a first base station server configured to form a blockchain transaction including the pseudonym ID and the vehicle data according to a verification result of the base station arithmetic unit, and to store the blockchain transaction.
 10. The communication system of claim 9, wherein the vehicle and the service provider share the initial secret value.
 11. The communication system of claim 10, wherein the vehicle generates the pseudonym ID through the initial secret value.
 12. The communication system of claim 9, further comprising: a first base station including the first base station server; and a second base station including a second base station server different from the first base station server, wherein the second base station server stores the blockchain transaction.
 13. The communication system of claim 12, wherein the second base station stores the initial secret value.
 14. The communication system of claim 12, wherein the first and second base station servers form a blockchain network.
 15. A vehicle comprising: a sensor configured to acquire vehicle data; a security module configured to store a private key, the security module comprising a random number generator configured to generate a plurality of first random numbers that vary over time; a wireless communication module configured to receive a public key generated by an operation of the private key and to receive an initial secret value provided by a service provider; and a vehicle arithmetic unit configured to generate a pseudonym ID based on the public key, wherein the wireless communication module is further configured to transmit the pseudonym ID to verify that the pseudonym ID is generated based on the initial secret value.
 16. The vehicle of claim 15, wherein the private key is not disclosed to an entity other than the security module.
 17. The vehicle of claim 15, wherein the public key is generated through an operation of the private key and the initial secret value provided by the service provider.
 18. The vehicle of claim 15, wherein the wireless communication module is configured to transmit a reward request to the service provider.
 19. The vehicle of claim 15, wherein the public key is shared with the service provider.
 20. The vehicle of claim 15, wherein the vehicle arithmetic unit is further configured to generate a first pseudonym ID corresponding to a second random number among the first random numbers, and a second pseudonym ID different from the first pseudonym ID and corresponding to a third random number different from the second random number among the first random numbers. 21-23. (canceled) 